User Interface
Voir aussi User experience.
Journaux liées à cette note :
Journal du mercredi 11 décembre 2024 à 17:08
En étudiant les Web Components, #JaiDécouvert wired-elements (demo : https://wiredjs.com/).
J'adore, je pense utiliser ces composants à l'avenir pour réaliser des prototypes d'applications. Je trouve que cela permet de bien exprimer l'idée qu'aucun travail n'a été fait sur le design de l'interface utilisateur et que ce n'était pas l'objectif.
wired-elements fait partie de l'organisation rough-stuff qui a aussi développé Rough.js que j'avais déjà croisé, mais également rough-notation (démo : https://roughnotation.com) que je viens de découvrir et que je pense utiliser à l'avenir.
Je pourrais peut-être m'en inspirer pour implémenter l'issue "Je souhaite arriver à afficher un { en svg entre les lignes du mois de juillet et décembre et d'y afficher un texte".
Journal du jeudi 05 décembre 2024 à 23:10
Ce matin, lors d'une discussion avec un client, le sujet de la densité des User Interface a été abordé. Cela m'a rappelé une note que j'avais rédigée le 2024-07-27.
Suite à cela, je me suis lancé dans des recherches en lien avec les grilles de Perspective que j'aime beaucoup (https://perspective.finos.org/blocks/editable/index.html).
#JaiDécouvert Glide Data Grid (https://grid.glideapps.com/) :
A ReactJS data grid with no compromises, outrageous performance, rich rendering and full TypeScript support.
Apparement, cette librairie utiliser HTML Canvas pour son rendering.
Dans ce thread Hacker News, #JaiDécouvert l'article "The Design Philosophy of Great Tables" (https://posit-dev.github.io/great-tables/blog/design-philosophy/).
J'ai consulter la page Components > Data Table de Evidence. J'aime beaucoup.
Journal du mardi 01 octobre 2024 à 11:55
Nouvelle #iteration du Projet 11 - "Première version d'un moteur web PKM".
Dans ma dernière itération du 31 août 2024, j'écrivais ceci :
Voici quelque erreur d'User Interface que je souhaite corriger.
Sur ce screenshot, les notes actuellement séparé par des
<hr />
ne sont pas facilement identifiable.
Depuis, j'ai travaillé dans la branche experimentation-ui
et pour le moment, j'ai le résultat suivant :
Je pense que les délimitations des notes sont maintenant mieux identifiables.
Problème User Interface que j'ai identifié : je pense que la présence d'un lien sur le titre de la note n'est pas facilement "découvrable".
Mon objectif est toujours le suivant :
Maintenant mon objectif est d'apporter le minimum de petite amélioration me permettant de remplacer l'instance notes.sklein.xyz propulsé actuellement par Obsidian Quartz par une version propulsé par
sklein-pkm-engine
.-- from
Voici la liste des choses que je dois implémenter pour atteindre cet objectif.
- Comme me l'a signalé à plusieurs reprises Alexandre, je dois améliorer le rendu responsive sur smartphone. Jusqu'à présent, je n'ai pas encore consacré de temps à ce sujet.
- Je dois améliorer le script d'import des données dans Elasticsearch. Pour le moment, ici, je commence par supprimer toutes les données avant d'effectuer l'importation des données.
Problème : les pages ne sont plus accessibles pendant l'exécution de ce script.
Je pense qu'après avoir traité ces deux tâches, je pourrais abandonner Obsidian Quartz et seulement ensuite implémenter toutes les idées pour améliorer mon Personal knowledge management "viewer".
Stratégie de grosse mise à jour de dépendances
Un ami m'a posé la question suivante :
Imaginez-vous face à un projet React avec des dépendances fortement obsolètes, fonctionnant sur une version de Node datant d’il y a cinq ans. En plus, il n’existe aucun test automatisé, qu'il s'agisse de tests unitaires ou d'intégration. Vous êtes contraint de réaliser cette mise à jour, car elle bloque les futurs développements et entraîne une accumulation excessive de dette technique. Quelle serait votre approche dans cette situation ?
- Affronter le problème de front : On prend le taureau par les cornes, on met tout à jour d’un coup, quitte à rencontrer des breaking changes ou des bugs non anticipés, que l’on corrigera rapidement (option rapide mais risquée).
- Prudence avant tout : On commence par ajouter des tests sur les parcours critiques, puis on met à jour les dépendances une par une, même si cela prend plus de temps (option lente mais sécurisée).
- Déléguer la décision : Ce n’est pas à moi de décider. Je présente ces options aux responsables et leur laisse la décision finale.
Avant de pouvoir répondre à cette question, j'ai besoin de déterminer la criticité business de cette application.
Est-ce que les décideurs acceptent que l'application puisse être en panne pendant 1 heure ? 1 jour ? 3 jours ? Ou aucune interruption n'est-elle tolérée ?
Si la réponse est "moins de 24 heures", alors je considère que l'application est critique.
Ensuite j'ai besoin de savoir si la mise à jour du projet peut être réaliser de manière iso-fonctionnelle (sans changement fonctionnel), sans changement d'User Interface et sans changement du modèle de donnée.
Si la réponse est positive, cela signifie qu'il sera facile de revenir à la version précédente en cas de problème, ce qui simplifie grandement le processus de refactoring.
Une de mes premières actions concrètes serait de "dockeriser" le projet pour faciliter son déploiement et permettre un retour rapide à une version antérieure si nécessaire.
Une autre question importante : d'autres développeurs interviendront-ils sur le projet pendant la période de refactoring ? Est-ce que des corrections de bugs ou de nouvelles fonctionnalités doivent être intégrées durant cette période ?
Si la réponse à l'une de ces questions est "oui", je recommande de dupliquer le projet dans deux dossiers distincts au sein d'un monorepo :
- Le premier dossier contiendra la version actuelle de l'application.
- Le second dossier contiendra la version en cours de refactoring.
Pendant toute la durée du refactoring, les corrections de bugs et les nouvelles fonctionnalités devront être appliquées aux deux versions.
Dans tous les cas, pour ne pas perdre pied, j'essaierai de mettre à jour l'application petit à petit.
Je commencerai par essayer de mettre à jour toutes les versions mineures des packages.
Ensuite, j'essaierai de me renseigner sur les breaking changes des mises à jour majeures des packages.
Ma réponse si l'application est critique
Si l'application est critique, alors il est inacceptable que les utilisateurs découvrent eux-mêmes les bugs et doivent contacter le support pour signaler les problèmes.
Si l'application ne comporte aucun test, je suppose qu'elle est testée manuellement et que son périmètre fonctionnel reste limité.
L'une de mes premières actions serait de définir un ou plusieurs scénarios de tests manuels prioritaires, que je ferais valider par les décideurs.
Ensuite, je proposerai aux décideurs d'envisager le développement de quelques tests fonctionnels automatisés. Une décision rationnelle à ce sujet dépendrait du temps nécessaire pour effectuer ces tests manuellement et, encore une fois, de la criticité business de l'application.
Enfin, je mettrai en place un système de déploiement progressif, de type A/B testing, permettant de déployer la nouvelle version de l'application à un nombre très restreint d'utilisateurs dans un premier temps.
Ma réponse si l'application est non critique
Si, d'un point de vue business, il est acceptable que les utilisateurs découvrent les bugs, alors je n'implémenterai pas de tests automatisés.
Je définirai tout de même quelques scénarios de tests manuels que le développeur seul exécutera.
Si cela ne demande pas trop de temps, je mettrai en place un système de déploiement progressif, tel que l'A/B testing, permettant de déployer la nouvelle version de l'application à un nombre restreint d'utilisateurs dans un premier temps.
Journal du vendredi 20 septembre 2024 à 10:25
#JaiDécouvert et un peu étudié Temporal (workflow management).
D'après ce que j'ai compris, Temporal a été initialement développé par les auteurs (Maxim Fateev et Samar Abbas) de Cadence.
Je me souviens d'avoir étudié Cadence vers 2019. J'ai l'impression que ce projet est encore très actif. #JeMeDemande quelles sont les réelles différences entre Temporal et Cadence 🤔.
Une première réponse à ma question :
- Temporal supporte les langages Go, Java, PHP, Python, TypeScript, dotNET alors que Cadence est limitée aux langages Go et Java.
- Cadence propose une UI nommée
cadence-web
qui semble plus minimaliste quetemporalio/ui
.
D'après ce que j'ai lu, Temporal est totalement open-source, sous licence MIT. L'entreprise Temporal propose une version hébergée (managée) nommée Temporal Cloud.
#JaiDécouvert un exemple de projet d'Order Management System codé en Go et basé sur Temporal : https://github.com/temporalio/reference-app-orders-go.
Je n'ai pas étudié le code source, mais c'est un sujet qui m'intéresse, étant donné que j'ai travaillé par le passé sur le développement d'un Order Management System 😉.
Journal du mardi 27 août 2024 à 10:51
#JaiLu Le retour de la vengeance des luddites technophiles de Ploum.
On ne peut pas. Un écran tactile nécessite de le regarder. On ne peut pas acquérir des réflexes moteurs sur un écran tactile.
Je suis tout à fait d'accord.
On ne peut pas former des marins capables d’agir intuitivement en situation de stress si l’interface change tous les 6 mois pour cause de mise à jour.
👍️
Dessin humoristique montrant une dame cherchant à acheter un ticket de train et se voyant rétorquer de rentrer chez elle, de créer un compte sur la plateforme, d’acheter le ticket, de le transférer sur son smartphone et que ce sera plus facile (aide appréciée pour retrouver l’auteur)
👍️
Contrairement à ce que la propagande nous fait croire, le luddisme n’est pas une opposition à la technologie. C’est une opposition à une forme de technologie appartenant à une minorité utilisée pour exploiter la majorité.
En effet et je vais faire attention de ne plus utiliser luddisme en ce sens.
D’après mon expérience, pour la majorité des utilisateurs, c’est une terrible période de stress où on ne peut plus faire confiance, certaines choses doivent être réapprises. Quand elles n’ont pas tout simplement disparu.
Tout à fait d'accord, je trouve qu'il y a généralement trop de grosse mise à jour.
Dernier exemple, il y a quelque jour, l'application Radio France sous Android que j'utilisé a subi une mise à jour importante de l'User Interface qui a entraîné chez moi, en plus des bugs, des notifications incessantes en boucle.
J'ai pesté, je me suis demandé pourquoi ils n'avaient pas opté pour une mise à jour plus légère de la version précédente.
Ou alors, pourquoi ne pas avoir développé une seconde application, m'offrant une transition en douceur, à mon rythme, lorsque je me sentirais prêt.
J'ai l'impression que, de manière générale, les mises à jour des projets libres sont plus progressives, ce que j'apprécie particulièrement.
J’entends régulièrement que Telegram serait une messagerie chiffrée. Ce n’est pas et n’a jamais été le cas.
Ce qui est fou, c'est qu'à force d'entendre cette propagante, je vérifie environ tous les 3 mois si je suis dans l'erreur ou non.
Mais comment ce mensonge est-il devenu populaire ? Tout simplement parce que Telegram offre une possibilité de créer un « secret chat » qui lui est techniquement chiffré. Il y a donc moyen d’avoir une conversation secrète sur Telegram, en théorie. Mais en pratique ce n’est pas le cas, car :
- Ces conversations secrètes ne fonctionnent que pour les conversations directes, pas pour les groupes.
- Ces conversations secrètes sont difficiles à mettre en place
- Ces conversations secrètes ne sont pas par défaut
- Ces conversations secrètes n’utilisent pas les standards de l’industrie cryptographique, mais une solution « maison » développée par des personnes n’ayant aucune expertise cryptographique
- L’entreprise Telegram (et le gouvernement russe) savent quand et avec qui vous avez initié un chat secret. Et ils peuvent le recouper avec la partie non secrète (imaginez un instant le « On passe sur le chat secret pour discuter de ça ? »).
😔
Ce qui confirme l’adage (que j’ai inventé) :
J'adore 👍️.
Journal du samedi 27 juillet 2024 à 14:00
#JaiLu le thread Hacker News "An experiment in UI density created with Svelte | Hacker News" et j'ai trouvé cela très intéressant.
Le bon dosage de la densité d'affichage est un élément très important dans mon expérience utilisateur.
#JaiDécouvert la librairie frontend web nommée DataTables (https://datatables.net/) implémentée en Javascript basée sur jQuery.
I'd like to think projects like these are somehow signaling a return to well designed but information dense, space saving interfaces ...
The amount of bloat, whitespace, extra spacing, "air" and other such waste — starting with (now Google-dead) "Material Design" has been egregious. —
#JaiDécouvert Perspective (https://perspective.finos.org/), j'aime beaucoup la densité des grilles. Voici un exemple en full screen : https://perspective.finos.org/blocks/editable/index.html.
J'aime sa densité et sa vitesse de rendu 👌.
This is interesting because it proves something to me about my vision and visual comprehension.
The "Grid" view is absolutely fine for me. The "Table" view is unworkable.
Intéressant 🤔.
J'ai regardé une partie de la vidéo de présentation du Bloomberg Terminal (https://www.youtube.com/watch?v=2ee-x6IXWK8), j'ai trouvé l'UI très intéressante.